feat(workspace): sync a bound workspace's custom skills into the project - #1172

TUI E2E showed the refresh never worked, for two independent reasons.
Reverting rather than deepening it: making it work is a design change,
not the few lines it looked like.

- The imperative `Skill.refresh()` facade runs on `makeRuntime`'s own
  runtime, so it invalidates a different Skill service instance than the
  one the live session reads. Proved with a harness test: after calling
  the facade, a skill written mid-session still did not appear.
- Even with that fixed, the gate could not fire. A bind syncs and
  consumes `changed: true`; the next `prompt` re-syncs, gets
  `changed: false`, and never invalidates.

An earlier run in this branch appeared to confirm the refresh working.
It did not — that process STARTED with the files already on disk, so
discovery found them on its first read. The result was confounded.

What is left is what is actually verified: the bundle syncs on bind and
at session start, and a session that starts with a bound project sees
the skill. A bind mid-session lands the files but needs a restart to
show them; the limit is now documented at the call site rather than
papered over by code that does not run.

This restores `skill/index.ts` and `test/skill/skill.test.ts` to be
byte-identical to origin/main — no `altimate_change` blocks to carry in
either upstream file — and removes the snapshot-generation counter,
which existed only to drive the invalidation.

… the cache

Without this, workspace skills never reach a project that was linked on a
different machine. The local binding cache is written only by an explicit
link, and `syncSkills` read only that cache — so a fresh clone of a repo a
teammate linked, a new machine, or cleared state all looked unbound. Running
`link` did not help: the server reports the project as already linked, the
picker answers "Already linked — nothing changed", and no local entry is
ever written. The project was left permanently without its workspace's
skills and with no way out from the CLI.

`resolveBinding` falls back to `WorkspaceApi.getBindingForProject` and caches
what it finds. Adopting a binding this way is a read, not an approval: the
lookup is access-controlled server-side — a workspace the caller cannot see
answers 404 exactly as an unbound remote does — so it can only surface a
binding the caller could already see.

It deliberately writes no `seededAt` and does not run the memory backfill.
Pulling a workspace's skills is read-only; pushing this machine's memory into
a shared workspace is a write, and that stays behind a real link.

A failed lookup is "unknown", not "unbound": it returns null, leaves whatever
is on disk alone, and is NOT memoized, so a network blip does not strand the
project for the rest of the process. Only a definite 404 is memoized, so an
unbound project pays one lookup per process rather than one per sync.

Verified against the live backend: with the binding present server-side and
the local cache wiped, `readLocalBinding` returns null while `resolveBinding`
adopts datamate 8, the bundle syncs, and the TUI lists `e2e-probe` after the
first turn. The written cache entry has no `seededAt`.

Both guards are mutation-checked: reverting to `readLocalBinding` fails the
fresh-clone test, and memoizing the error path fails the retry test.

A skill added to the workspace previously never reached a running session:
the pull happened once per process, so it took a restart. This polls on an
interval and refreshes the registry in place when something actually moved.

Corrects the premise of the earlier revert. That change claimed the
imperative `Skill.refresh()` facade invalidates a different service instance
than the live session reads. It does not. `attach()` propagates the instance
ALS into the facade's runtime, so a call from plain async code running under
a session reaches that session's caches. The revert's harness provided the
instance through Effect context only, never ALS, which is why it appeared to
fail. Verified the other way round with a real `Instance.provide`: read,
write a new skill, read again (still cached), refresh, read — the third read
sees it.

The wiring was the actual bug. A bind consumed `changed: true`, so the next
turn's sync reported `changed: false` and the gate never fired.

- `skill-sync`: `recentlySynced` gates the per-message poll on a 5-minute
  interval. Once per process means a skill added upstream never arrives;
  every turn means an HTTP round trip in the latency-measured path. The list
  is Postgres-only server-side, so a no-op check is cheap.
- `prompt`: waits at most 2s for the sync, and does NOT cancel it past that.
  The workspace request budget is 15s — long enough that a slow backend would
  otherwise read as the agent hanging before it starts. Past the bound the
  sync completes and lands on a later turn.
- `skill/index.ts`: `Skill.refresh()` restored, invalidating both
  `discovered` and `state`.

Also stopped this file's test leaking `ALTIMATE_WORKSPACE` into other suites.
It was set at module load, so other files' prompt path attempted a real sync
against this sandbox's credentials and burned 15s timeouts — which is how the
unbounded wait above got noticed.

E2E: with a session already synced, a skill created and attached in the SaaS
appears in the TUI's list after a later turn, no restart. Guards mutation
checked — pinning `recentlySynced` true or false, and dropping either half of
`refresh`, each fail a test.

`memory-sync` read only the local binding cache, which is written solely by
an explicit link. Any directory holding a repo that IS bound therefore
mirrored nothing, silently: a git worktree, a second clone of the same repo,
a teammate's checkout, a new machine, cleared state. `currentBinding`
returned null and the mirror wrote nothing — no error, no warning.

Worktrees make this ordinary rather than rare. The cache is keyed by
directory while the server matches on git remote first, so every worktree of
a linked repo is a local miss and a server hit.

Same one-line switch already made for skills, to the same `resolveBinding`:
local cache first, else the server, cached for next time. It writes no
`seededAt` and does not run the backfill, so adopting a binding still does
not push this machine's memory into a shared workspace — that stays behind a
real link. Pulling is safe; pushing is not.

The import is aliased because `syncInternals.resolveBinding` is an unrelated
test seam in this module.

Covered both ways: a directory bound only on the server now mirrors, and a
genuinely unbound one still does not. Reverting to `readLocalBinding` fails
the first. Note the second case does not distinguish a null binding from one
whose workspace has memory disabled — an invented-binding mutation survives
it — but that is not a plausible regression and the test was left honest
rather than fitted to it.

…ll sync

An independent audit of the feature surfaced twenty failure modes. These are
the eight that are security, data-loss or silent-no-op, all confirmed in the
code before fixing.

**Path traversal.** `public_id` went straight into `path.join(staging, id,
file.path)`. Only the per-file path was guarded, and the escape happens one
component earlier — a malformed or compromised listing could write anywhere
the process can. Now rejected unless it is a single usable path component.

**Data loss.** The managed directory was replaced or deleted wholesale with
no ownership check. Anything a user had at that path — a hand-written skill,
an older tool's output — was destroyed by a routine sync. The name is ours by
convention, and convention is not ownership: absent or carrying our manifest
now means ours, anything else is left alone and the sync declines.

**Partial snapshots were discoverable.** Staging was `_workspace.staging-<pid>`,
a sibling inside `.altimate-code/skill/`, which discovery globs as
`{skill,skills}/**/SKILL.md`. Half-downloaded bundles could be loaded as real
skills, and a SIGKILL left a permanently discoverable tree. Staging moved to
`.altimate-code/skill-staging/`, outside the scan, and stale trees are swept.

**A bind left the registry stale for the process lifetime.** The bind path
syncs and stamps the poll window, so the next turn skipped the only code that
refreshes — newly linked skills stayed invisible until restart. Snapshot
changes and registry refreshes are now tracked separately, so a turn notices
work another caller did without re-fetching.

**Failures consumed the poll window.** `lastSyncedAt` advanced even when the
sync threw, suppressing retry for a full interval on a blip. Only a run that
actually read the workspace list stamps now.

**Account switches kept the previous tenant's skills.** The poll window was
keyed on directory alone, so switching accounts inside the interval skipped
the very poll that would have noticed. It is now checked against the
credentials in play at that moment.

**A damaged snapshot was declared current forever.** `upToDate` compared only
ids and `updated_at`; a deleted or truncated file was never repaired. It now
verifies each file against the sizes the manifest already records.

**Committing another workspace's skills.** The tree is a server-derived
mirror with no business in a user's history, and it showed up in `git status`
for every bound project. It now carries a `.gitignore` of `*`, staged so it
lands atomically with the snapshot.

Also: the file endpoint's echoed `path` is now checked against the one
requested — no checksum exists, so a mis-routed same-length response would
otherwise be stored under the wrong name. And the negative binding cache is
tenant-scoped with a TTL, instead of a permanent process-wide memo that made
a newly linked project invisible until restart.

Every guard is mutation-checked. Two notes on that: the staging test had to
observe mid-sync, since staging is removed on success and checking afterwards
proved nothing; and the failure-stamping guard is not independently
observable, because the account check already forces a re-poll — it is kept as
defence, not because a test pins it.

E2E against a live backend: bundle syncs with the ignore file, no strays in
the scanned directory, `git status` clean, a deleted file is repaired rather
than declared current, and a hand-written directory survives with the sync
declining.

Second pass over the audit findings.

**The swap had a window with no snapshot.** Publishing did `rm(root)` then
`rename(staging, root)`; a crash or a reader in between saw the skills vanish,
and the catch still logged "kept the existing snapshot". The live tree is now
renamed aside, the new one moved into place, and the retired tree deleted only
after that succeeds — with the old one restored if the swap fails.

**An inconsistent page could delete a good snapshot.** `{items: [], total: 4}`
was read as an empty workspace, and "empty" is the one answer that removes the
tree. A page whose envelope claims rows while returning none is now an error.

**No ceiling on a sync.** Every file is read fully into memory before it
reaches disk, and nothing upstream bounds a workspace, so one oversized bundle
was an OOM rather than a failed sync. Capped at 2000 files / 32 MB, counted on
the advertised inventory before anything downloads.

**The header comment was wrong about activation**, in a way that matters:
`alwaysApply` and `applyPaths` DO survive into `Info` and are injected by
`collectAutoLoadedSkills` into every applicable system prompt, with no
Skill-tool call and no permission prompt. So anyone who can upload a skill to a
workspace can put standing instructions into every bound member's prompts. The
comment now says so. Deliberately NOT changed in code: whether workspace skills
may auto-activate is a product decision, and stripping frontmatter an author
wrote is not a call this module should make silently. Also corrected the
documented file-endpoint shape, still stale from the original reading.

Tests: an inconsistent empty page, a bundle past the ceiling, and — the gap the
audit was most pointed about — a synced bundle that is actually a loadable
skill. The existing fixtures assert only that bytes reached disk, which does
not show the feature works; this one parses the frontmatter, checks the
bundled reference survived, and checks the path is where discovery globs.

Two guards are honestly not pinned. The ceiling test counts files rather than
bytes, because an oversized `size` trips the integrity check first and would
pass without any ceiling existing. And the atomic swap has no test: proving it
needs a fault injected between two renames, which this harness cannot do — it
is kept because it is strictly better, not because a test holds it.

E2E: both workspace skills sync with valid frontmatter, the ignore file lands,
no strays in the scanned directory, no staging left behind but its own ignore
file, and `git status` is clean.

Disconnecting an account left the workspace's skills on disk and loading.
`getCredentials()` threw, the sync returned early, and the snapshot stayed —
discovery reads whatever is on disk without consulting the manifest, so a
disconnected user kept getting the workspace's skills. Turning
`ALTIMATE_WORKSPACE` off behaved the same way: the opt-out did not take
effect until the files were deleted by hand.

That compounds with a property documented in the previous commit: a skill
carrying `alwaysApply` is injected into every applicable system prompt with
no tool call, so what kept loading is also what can act on its own.

Both paths now remove the snapshot, and only a tree this client owns.

Disconnected is deliberately distinguished from "could not read the
credentials". The first is a decision the user made and must take effect; the
second is unknown, and unknown never destroys a snapshot — the same rule the
list response and the binding lookup already follow. A corrupt credentials
file therefore keeps the skills.

The check runs before `resolveBinding`, which needs credentials itself: placed
after, a disconnected client returned on a null binding and never reached it.
That is not hypothetical — the first version of this fix did exactly that and
the test caught it.

Verified live: sync -> 2 skills; disconnect -> removed; reconnect -> 2 skills
again; corrupt credentials -> kept. Each guard mutation-checked, including the
destructive mutation that treats an unreadable file as a disconnect.

Seven reviewers, verdict REQUEST CHANGES. This covers the four blocking
findings plus everything cheap enough to land with them.

**C1 — sweep followed symlinks and deleted outside the tree.** `readdir`
follows links, so a repo shipping `.altimate-code/skill-staging -> ../..`
(git tracks symlinks, so it survives a clone) had the sweep enumerate and
recursively delete the target. Symlinked ANCESTORS were equally exposed:
every mkdir, rename and write resolves through them. Nothing here should
traverse a link, so `pathsAreReal` refuses rather than trying to make
traversal safe, and the sweep lstats each entry and unlinks a link instead
of recursing into it.

**M1 — every readdir failure meant "ours", and then deleted.** ENOTDIR (a
plain file at the path) and EACCES both returned true, handing a user's file
to `fs.rm` — the exact outcome the guard exists to prevent. Only ENOENT means
absent now. Ownership also rested on the FILENAME `.manifest.json`; a
directory holding an unrelated or corrupt one was deleted wholesale. It must
now parse as ours.

**M2 (partial) — the sweep destroyed other processes' in-flight staging.**
A sibling's live `pending-<pid>` was deleted mid-write, so it published a
snapshot missing everything written before the sweep with a manifest claiming
those files. Entries owned by a live PID are now left alone. The full
inter-process lock is deferred; this removes the path that publishes a
corrupt tree.

**M4 — an account switch left the previous tenant's skills live.**
`resolveBinding` collapses "confirmed unbound" and "lookup failed" into null,
and the early return on that happened BEFORE the foreign-manifest purge — so
switching to an account with no binding kept tenant A's skills on disk and in
tenant B's prompts, with every retry hitting the same return. Credentials and
the manifest are now read first, and a snapshot belonging to another account
is dropped without waiting for a binding that will never arrive.

Also landed:

- **M5 (escaping half)** — `skill.content` went raw between
  `<auto_loaded_skill>` tags while only the name was escaped, so a body
  containing the closing tag broke out and continued as unwrapped
  system-prompt text, able to impersonate the harness's own framing. Skill
  bodies are remote content now, which is what makes this reachable.
- **M6 (OOM half)** — the response body was buffered whole, so a file declared
  as 10 bytes returning 500 MB crashed before any size check. Bounded by
  Content-Length and by a cut-off on the stream itself.
- **M7** — a missing or nonsense `pages` silently became 1, turning a partial
  first page into "the whole workspace" and pruning the rest. It must now be a
  finite integer >= 1, and the echoed `page` must match the one requested.
- **m1** — the echoed-path identity check was skipped when the field was
  absent, which is precisely the mis-routed case it was written for.
- **m2/n1** — `.manifest.json` and `.gitignore` are reserved as ids (either
  would break that workspace's sync permanently with EISDIR); NUL check made
  symmetrical across both path guards.
- **m4** — a `public_id` repeated across pages made `upToDate` permanently
  false and re-downloaded the workspace every poll.
- **m5** — joining an in-flight sync returned a hard-coded `changed:false`
  rather than the run's real outcome.
- **m6** — `isEnabled()` is checked before the credentials read: it removes a
  per-message file read when the feature is off, and closes the opposite
  hole where turning the flag off after a sync left the snapshot live for a
  full poll interval.

Tests for each, all mutation-checked. Two notes on that: a plain file at the
managed path is caught by C1's symlink check before M1's error handling, so
M1 is pinned by the corrupt- and foreign-manifest cases instead; and the
review was right that "a synced bundle is a real skill discovery can load"
never invoked discovery — it now claims only shape, and the end-to-end claim
is made in test/skill/skill.test.ts where the instance harness exists.

Added the multi-page pagination coverage all seven reviewers asked for.

Re-verified against the live backend after the changes: three skills sync,
no staging left behind, and a model invokes a synced skill and reads its
bundled reference.

…estly

The review found the code and the PR description disagreeing about whether
memory upload requires an explicit link. The code is what was intended; the
prose overclaimed.

Precisely: adopting a server-side binding DOES enable the ongoing memory
mirror, which POSTs blocks to the workspace. Only the one-shot backfill of
memory this machine already held stays behind an explicit link, via
`seededAt`. The PR said "pushing this machine's memory into a shared workspace
stays behind a real link", which is true of the backfill and not of the
mirror. The description is corrected rather than the behaviour: a worktree of
a linked repo is the same project by the same user, and a mirror that silently
does nothing there is the bug being fixed.

`CachedBinding.adopted` now records how a row was obtained. `resolveBinding`
writes into the same cache file `recordApprovedBinding` does, so without a
marker no consumer can tell adoption from approval — and the absent `seededAt`
is not a substitute, since only the memory backfill consults it. Any future
gate meaning "the user linked this" can now require `!adopted` instead of
inheriting adopted rows for free.

The memory test that encodes this decision now says so in as many words, with
the reasoning and an instruction to flip it if the trade is ever reversed.

…when off

CI caught two things.

**Marker Guard**: `refresh` was added to the upstream `Service.of(...)` line
outside the marker block that introduced it. Wrapped.

**The per-turn hook did work even with the feature off.** `recentlySynced`
returns false when disabled, so every turn still called `syncSkills`, which
stat'd the managed path before returning. Now the whole block is skipped.
That path runs for every user, including the ones who never opted in.

Written as a conditional rather than an early `return`: inside `prompt`'s try
block a `return` exits `prompt` itself and skips `createUserMessage` — the
message the function exists to produce. My first version of this had that bug.

Four bot reviewers on the PR. The most important one caught a regression I
introduced two commits ago.

**Opt-out stopped removing the snapshot (Kilo).** The `isEnabled()` guard I
added to keep the per-turn hook off the latency path made `syncSkills`'s
disabled branch unreachable — and that branch is the ONLY thing that removes an
already-synced snapshot. Discovery does not consult the flag, so after
disabling the feature the skills stayed on disk and kept loading,
`alwaysApply` included. I had built that deactivation deliberately, then broke
it while fixing something else. The hook now runs the disabled branch (a single
stat) and refreshes the registry when it drops a snapshot.

**A symlinked `.altimate-code` bypassed the symlink guard on opt-out (cubic
P1).** The disabled branch deactivates before the check inside `run`, so the
purge could follow a link out of the project. Gated on the same check.

**A confirmed unbind left the workspace's skills active (cubic P1).**
`resolveBinding` collapsed "the server says unbound" and "we could not find
out" into null, and the sync returned on both. Binding resolution is now
tri-state: a confirmed unbind takes the snapshot out of service, and unknown
still changes nothing — deleting on a network blip would wipe a snapshot the
user is entitled to.

**A malformed 2xx binding body crashed the sync (cubic P2).** The dereference
sat outside the lookup's try. It is validated now and treated as unknown.

**The response cap applied to every request (cubic P2).** The 8 MB bound I
added for skill downloads also hit memory `/list`, which embeds block content
and is deliberately not capped server-side — a regression risk for requests
that work today. It is opt-in now, set only on skill file downloads, and the
bodyless branch that bypassed it enforces it too.

**The wait timer was never cleared (CodeRabbit).** An armed timer keeps the
event loop alive, so a short-lived `run` lingered for the rest of the bound,
once per turn.

**Test isolation (cubic P2, CodeRabbit).** `XDG_STATE_HOME` and
`OPENCODE_TEST_HOME` were set at module load, so another file in the same bun
worker had its config, state and credential reads redirected into this
sandbox. Scoped per test, like the workspace flag already was. The memory
suite's `serverBinding` fixture is reset per test for the same reason.

Deferred with reasons: revalidating cached POSITIVE bindings on a TTL (cubic
P1) — it needs a rebind elsewhere during a live process, and the fix trades
against offline behaviour; and a no-op fixture assignment (cubic P3).

Every fix has a test, all mutation-checked. The symlink-purge test needed a
tree at the link target to be sensitive at all — without one it passed whether
or not the guard existed.

Re-verified against the live backend: three skills sync, no staging residue,
`git status` clean, and a model invokes a synced skill and reads its bundled
reference.

Two reviewers flagged this independently — cubic P1 (confidence 9) and
CodeRabbit Major, filed as sensitive-data exposure. I had deferred it as
pilot-rare. That was wrong, and the reason is that the local cache is written
by an explicit link and otherwise never expires: once a project is rebound or
detached in the SaaS, this machine keeps serving the OLD workspace's skills
forever, not just until some window closes. `alwaysApply` bodies included.

The server is authoritative now. A cached binding is trusted inside a
5-minute window; past it the server is asked:

- confirmed unbound -> the cached row is dropped and the snapshot taken out
  of service, so a later read cannot resurrect it from disk
- rebound elsewhere -> the server's answer replaces the cached one
- unreachable -> the cache stands. Revalidation must not tear down a working
  setup over a network blip, which is the same error-is-not-empty rule the
  rest of this feature follows

Adoption stamps the validation clock, so a freshly adopted binding is not
immediately re-checked.

Tests for all three outcomes, including the cached-binding-with-404 case
CodeRabbit asked for. Mutation-checked: trusting the cache forever, treating
unreachable as unbound, and leaving the stale row behind each fail.

Two test-fixture corrections that were mine, not the code's: a revalidation
lookup is not a detail fetch (the unchanged-workspace counter) and not memory
traffic (the re-seed counter), and my first offline test served an empty list,
so the snapshot was deleted for an entirely correct but unrelated reason.

Also REVERTED part of the previous commit. cubic asked for XDG_STATE_HOME and
OPENCODE_TEST_HOME to be scoped per test like the workspace flag. Doing that
broke seven tests in onboarding/materialize.test.ts, which began materializing
into the real home directory: files sharing a bun worker set these at module
load, and restoring "the original" after each test deletes theirs mid-run.
Flipping them per test is worse than leaving them set. The reasoning is now a
comment there so the next reader does not retry it.

…ver opted in

CI failed on a test I did break, and I had been calling it a load flake.

`running subtask preserves metadata after tool-call transition` passes 3/3 on
main and failed 2/3 on this branch IN ISOLATION — not under parallel load.
Removing my `prompt` hook made it pass 3/3 again, which is what settled it.

The cause is not cost. Instrumented, the hook took 2ms and the module import
89ms once. It is the `await` itself: awaiting anything before
`createUserMessage` inserts an event-loop tick that reorders the turn against
the forked `prompt.loop` fiber the test races. Adding the timing probe changed
the interleaving enough to make it pass, which is the tell.

So the flag is now read synchronously, and when the feature is off the hook
adds no await at all — no dynamic import on the turn's path either. Somebody
who never enabled workspaces should not have their turn scheduling touched.

Opting out still takes effect. That cleanup runs detached rather than awaited:
discovery loads whatever is on disk without consulting the flag, so a stale
snapshot must still be removed, but nothing in the turn is waiting on it —
there is no snapshot for this turn to use.

Verified: 5/5 clean on the previously-failing file, and the full CI-equivalent
suite (12361 tests, 602 files, --timeout 90000) at 11491 pass / 0 fail.

On process: I had been running typecheck, oxlint and a four-directory test
subset — 6600 tests — while CI runs the full 12361 and a marker-guard job I
never ran locally at all. That is how the earlier marker break reached CI too.
Both are now part of the pre-push routine.

A workspace linked while a session was already open never reached the
agent. Files synced to disk correctly, but the registry was never
refreshed, so the model reported only `customize-opencode` as available
for the rest of the session. Confirmed end to end on the gateway: two
clean turns after a link, both reporting the workspace's skills absent.

The handoff was the bug. A bind stamped an in-process `Map` and the turn
that could refresh read a different copy of it. Instrumenting both sides
showed the bind writing one module record and the hook reading another
in the same pid, and moving the tables onto `globalThis` changed nothing
— these run on separate threads, which share neither module registry nor
globals. No in-memory signal can cross that boundary.

`registryStale` now compares a fingerprint taken from disk: the mtime of
the snapshot manifest, which every changing sync swaps into place and
every deactivate removes. It therefore moves on exactly the events a
refresh must follow, in both directions, and every thread reads the same
number. `snapshotChangedAt` becomes dead and is dropped.

Two smaller fixes ride along:

- The remaining tables move onto a symbol-keyed global. Same-realm copies
  of this module were forking `inFlight` too, which let a bind and a turn
  stage and swap the same project concurrently.
- `refreshSkillRegistry` invalidates through the in-context Effect
  services rather than the imperative facades. Discovery re-derives its
  roots from `Config.directories()`, and a facade-level invalidate leaves
  the boot-time miss for `.altimate-code/` in place.

A bound project now pays one config invalidation on its first turn: disk
alone cannot tell a snapshot that predates boot from one a bind just
wrote, and rescanning a current registry is cheap next to missing a new
one. Unbound projects pay nothing.

Tests assert the disk-driven property directly — the manifest mtime moves
with no sync having run in this module, and a purge is reported too. Both
die when `snapshotFingerprint` is mutated to a constant.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012wmN54fRA4WLgdVJVunaNk

Opt-out no longer lets a stale snapshot into the turn. The purge was
detached so an opted-out user would not pay an event-loop tick, on the
stated assumption that "there is no snapshot for this turn to use". That
assumption is wrong: a run with the flag ON leaves a snapshot behind and
turning the flag off does not delete it, so a later opted-out turn can
find one and `createUserMessage` materialised those skills — including
`alwaysApply` instructions — before the cleanup ran. The gate is now a
synchronous `existsSync`, awaiting the purge only when a snapshot is
actually present. A user who never opted in has no directory, so that
path costs one `stat` and does not even load the sync module, which is
what the detached version was protecting.

`syncSkills` joins the in-flight map before reading the flag, so the
purge is serialised against a sync. Previously an enabled run already
past its own flag check could republish `_workspace` moments after a
disabled run deleted it, leaving a snapshot on disk for a feature that
is off.

Binding revalidation had three defects, all in one region:

- An explicit link inside `MISS_TTL_MS` of a turn taken while unlinked
  was undone by its own revalidation: `lookupBinding` answered `unbound`
  from the negative memo without contacting the server, and the caller
  treated that as authoritative and deleted the row the link had just
  written. A bind now retires the memo and counts as server-validated —
  the link is what created the binding.
- Confirming a cached binding rewrote it as an adopted row, dropping
  `seededAt` (re-running the whole memory backfill on a later re-link)
  and relabelling an explicit link. Confirmation now preserves both.
- `lastValidatedAt` was keyed by directory alone while the sibling memo
  is account-scoped, so after an account switch one account's timestamp
  suppressed revalidation of the other's binding. Both now share one
  account-scoped key.

Also widens binding-identity validation to the optional string fields,
and drops a nested `altimate_change` marker inside an already-marked
block in `skill/index.ts`.

Tests cover the purge/sync serialisation and the link-inside-the-miss
-window case; both fail when the fix is mutated out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012wmN54fRA4WLgdVJVunaNk

`syncSkills` runs its no-credentials `deactivate` at the top of `run`,
before the `pathsAreReal` check that the comment below it describes as
the guard for every write, rename and sweep. A symlinked
`.altimate-code` therefore had `removeManaged` and `sweepStaging` resolve
through the link and delete the target's `skill/_workspace` — the same
hazard already fixed for the opt-out purge, on the one path that still
lacked its own guard.

Every other deletion in this function is guarded; this one now matches.

The test gives the link target a tree the purge would remove, so it fails
if the guard is taken back out rather than passing because there was
nothing there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012wmN54fRA4WLgdVJVunaNk

`altimate-code run` never received a workspace's skills on a project that
had not synced before. The turn waits at most 2s for the sync, a cold sync
takes ~7.6s against a local backend, and the process exits the moment the
turn drains — discarding the staged tree. Because nothing was persisted,
the next `run` started cold and lost the same race, so such a project
never got its skills however many times it was run. Three consecutive
runs left zero bundles on disk; a turn padded to 12s landed all three,
which is what identified the race.

The TUI never showed this because it outlives the sync, and the unit
tests could not: they await `syncSkills` directly, so the one thing that
breaks — the process ending first — never happens.

`run` now awaits any sync still in flight once the turn has drained, the
same reasoning as `awaitBackfill` on the bind path, capped so a hung
request cannot hold the process open. A cold short-turn run now lands the
full snapshot in 7.7s total.

The test asserts the snapshot is still absent at the moment the flush is
entered, so it fails if the flush ever stops waiting rather than passing
on a sync that had already finished.

Verified end to end against a local backend and the gateway model, over
the acceptance criteria in the linked issue: skills reach the agent with
their `references/` intact, a server-only binding adopts, the tree stays
out of git, a skill added to the workspace reaches the project and gets
used, opting out and disconnecting both stop serving the skills,
reconnecting restores them, an unreachable backend leaves the snapshot
untouched, and a directory the client did not create is never replaced.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012wmN54fRA4WLgdVJVunaNk